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Abstract — Recommended approaches for shuttle small 
payload integration and test (I&T) are presented. The paper 
is intended for consideration by developers of small shuttle 
payloads, including I&T managers, project managers, and 
system engineers. Examples and lessons learned are 
presented based on the extensive history of the NASA’s 
Hitchhiker project. 

All aspects of I&T are presented, including: 

• I&T team responsibilities, coordination, and 
communication; 

• Flight hardware handling practices; 

• Documentation and configuration management; 

• I&T considerations for payload development; 

• I&T at the development facility; 

• Prelaunch operations, transfer, orbiter integration 
and interface testing; 

• Postflight operations. 

This paper is of special interest to those payload projects 
which have small budgets and few resources: That is, the 
truly "faster, cheaper, better" projects. All shuttle small 
payload developers are strongly encouraged to apply these 
guidelines during I&T planning and ground operations to 
take full advantage of today’s limited resources and to help 
ensure mission success. 
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1 . Introduction 

Overview and Scope 

Integration and test (I&T) of small shuttle payloads, such as 
those historically designated as “Class-D is typically 
accomplished on a much smaller scale than most other 
human-rated space projects. The streamlined nature of these 
projects affords a level of teamwork and flexibility not 
possible with larger projects, such as Space Station or 
Hubble Space Telescope. Smaller team size, on the order of 
a dozen total, means each individual has a distinctly 
significant role in the development, integration, and test of 
the spacecraft. 

Presented here are some guidelines and recommendations for 
small shuttle payload I&T based, in part, on lessons learned 
over the 18-year history of Hitchhiker payloads. 
Hitchhikers, along with Get-Away-Specials, are “in-house” 
projects of the Shuttle Small Payloads Project Office 
(SSPPO) at NASA’s Goddard Space Flight Center (GSFC). 

After 29 missions involving over 50 separate instruments, 
the Hitchhiker project has gained a wealth of experience 
integrating and testing shuttle payloads with a streamlined 
cadre of I&T personnel. Although many details and 
examples presented here are based on Hitchhiker, the basic 
approaches are directly transferable to any small shuttle 
payload project. Current or prospective payload developers, 
and in particular I&T managers, are encouraged to consider 
and apply these guidelines during I&T planning and ground 
operations. 
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lead the operation. 


In addition, I&T suggestions for small shuttle payload 
customers can be found in [1], An example of a customer 
accommodations and services provided by the Hitchhiker 
carrier, as well as additional details regarding shuttle I&T, 
is in [2], Some additional lessons learned can be found in 

[3]. 

Since the focus of this paper is on payload-level integration 
and test, details regarding design and qualification testing of 
individual components and subsystems is not included. 

Definitions 

Carrier — The payload infrastructure which acts as a 
mechanical and electrical interface between the payload 
customers) and the orbiter. The carrier not only supports 
the customer hardware, but may also provide services such 
as power, command and data handling (C&DH), and 
thermal control. 

Customer — The user (principal investigator or other 
instrument representative) of the payload carrier who 
develops and delivers the instrument to the carrier 
organization. Often, "customer” is used synonymously to 
refer to the instrument hardware itself (as in "customer 
interfaces"). However, at Kennedy Space Center (KSC), the 
term "payload customer" typically refers to the overall 
integrated payload organization. 

Experiment — The scientific research, technology 

demonstration, or other operation conducted during the 
mission using the instrument. 

Instrument — The customer hardware subassembly, one or 
more of which are integrated onto the payload carrier. 

Integration and Test — The process by which a payload is 
assembled and tested for flight. This includes I&T at the 
payload development facility, as well as that at the launch 
site (KSC). 

I& T Manager — The person responsible for coordinating the 
I&T team, and for directing payload I&T from development 
through postflight deintegration. 

I&T Team — A multidisciplinary group of engineers and 
technicians responsible for developing, integrating, and 
testing a payload to prepare it for flight. Areas of expertise 
may include such disciplines as mechanical, electrical, and 
thermal engineering, as well as ground data systems.. 

Payload — The integrated spacecraft assembly, composed of a 
flight carrier supporting one or more instruments. The term 
is also used here to refer to the payload development 
organization, responsible for delivering the integrated 
payload to KSC. 

Task Leader — The member of the I&T team who is 
responsible for directing a particular operation. This may be 
an engineer, technician, or other individual who is 
intimately familiar with the procedure, and fully qualified to 
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2, I&T Miscellaneous 

The I&T Team 

Team Responsibilities — The I&T team for a given spacecraft 
is generally composed of engineers and technicians 
representing a range of disciplines, such as mechanical, 
electrical, and thermal engineering. For some autonomous 
free-fliers (such as Spartans), the I&T team may also include 
disciplines such as attitude control and propulsion. 

Prior to the start of I&T, all I&T personnel must 
understand their assigned responsibilities. Lead engineers 
must always be kept apprised of all significant developments 
and meetings, as they are the prime points of contact for 
their areas of expertise. 

During I&T itself, personnel supporting a particular 
operation are responsible for assuring that all necessary 
equipment is on-hand, calibrated (If required), and properly 
configured. They should also be on-station prior to start of 
a procedure and be present (or at least on-call) until the 
operation is completed. This could be important if, for 
example, any troubleshooting is necessary that requires the 
support of specific individuals. 

I&T Manager Responsibilities — The following is a 
summary of responsibilities which may fall under the 
purview of the I&T manager for small shuttle payloads: 

• Primary point-of-contact regarding integrated 
payload I&T issues; 

• Coordinates I&T team and operations, including 
subsystem, customer, facilities, and support 
services; 

• Works with project management to prioritize and 
resolve conflicts regarding schedule, support and 
resources; 

• Develops integrated payload I&T plan and 
procedures; 

• Develops and maintains schedules for integrated 
payload I&T at the development facility and launch 
site; 

• Informs I&T Team, project management, and 

individual instrument customers of I&T status and 
issues; 

• Provides input to payload design issues which may 
affect I&T; 

• Provides inputs to shuttle Payload Integration Plan 
(PIP), Interface Control Document (ICD), 
Installation Requirements Document (IRD), and 
safety data packages; 

• Primary point-of contact with KSC for 

requirements, scheduling, procedures, and 

operations at the launch site; 

• Develops “lessons learned” following each 

mission, as applicable. 

Ultimately, the I&T manager’s primary job is to facilitate 
the I&T of the payload in as safe and timely a manner as 
possible. 
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I&T Coordination 

Meetings — Regular I&T meetings are suggested to help 
keep the I&T team informed. The frequency of I&T team 
meetings depends on many factors: 

• The amount of time until start of I&T; that is, 
I&T meetings should be more frequent (e.g., once 
a week) as the start of I&T becomes imminent; 

• The criticality of the operations at-hand; e.g., in 
general, hazardous operations require more intense 
team coordination; 

• The level of I&T activity for the payload itself; 
i.e., when the team is involved in an intense level 
of activity (e.g., multi-day operations), daily I&T 
team meetings may be warranted; these can be as 
simple as stand-up status meetings in an off-line 
lab or “on the floor”; 

• The frequency of project-level meetings, which in 
general should be inversely proportional to the 
frequency of I&T meetings; 

• The level of activity within the project as a whole; 
that is, the amount of time which the members cf 
the I&T team have available to attend meetings 
while supporting other activities. 

It may also be desirable, if time allows, to organize an "I&T 
retreat" for the team early during the payload design phase. 
This provides an informal atmosphere for the team to 
brainstorm regarding I&T flow and any design issues which 
may affect I&T. Success of such a retreat requires that the 
I&T team, especially the lead engineers, commit themselves 
to attend without interruptions. A remote meeting location 
generally helps facilitate uninterrupted participation. 

Schedules — An I&T schedule is developed based on the 
KSC delivery and launch schedules, on inputs from the 
entire team and the customers, and finally on past 
experience. The schedule should be realistic: not overly 

ambitious, yet also not overly conservative. Even some 
contingency in the schedule is actually realistic, since there 
are always unanticipated delays and problems. 

Use of Performance Evaluation Review Technique (PERT) 
charts is sometimes helpful in the early planning stages to 
help identify I&T flow. However, maintaining accuracy cf 
large PERT’s over time is generally manpower intensive, 
particularly for smaller projects. More basic scheduling 
tools are recommended for frequent tracking of I&T, such as 
one-page “Gaants” to highlight major I&T milestones. In 
the case of KSC I&T, which tends to be a short-duration, 
intense level of activity, a daily line-by-line summary of 
operations is useful. Ultimately, the I&T manager should 
utilize the scheduling tool which he or she finds most 
effective. 

Ideally, the I&T schedule should be reviewed by the project 
management before general distribution to the team and 
customers. The I&T team must understand that the I&T 
schedule is managed (by definition) by the I&T manager. 
Any issues or conflicts should be brought to the attention of 
the I&T manager as soon as possible after they are 
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discovered, so the schedule can be adjusted as necessary. 
Handling of Flight Hardware 

General I&T Practices — Each member of the I&T team, 
particularly those who will be directly handling the flight 
hardware, must be familiar with basic flight hardware 
handling practices. The following "common-sense" 
practices may seem trivial at first-glance, but may ultimately 
be the keys to mission success and safety: 

• Before entering a clean environment, utilize shoe 
cleaners when available and properly don all 
necessary garments prior to entering clean area. 

• Do not lay tools, test equipment, paperwork, or 
other miscellaneous items on top of flight 
hardware. 

• Minimize, if not eliminate, debris ("foreign-object 
debris,” or FOD) in I&T areas; this includes 
particulates as well as unneeded tools and 
equipment. Take the initiative to report facility 
cleanliness issues. 

• Use gloves when handling cleaned flight hardware, 

including cable harnesses. Replace gloves as 

necessary to avoid contaminating clean hardware. 

• Use conductive gloves and wrist-stats when 

handling any hardware containing electronic 

components or ordnance. 

• Fabricate/rework hardware in an area away from 
flight hardware, preferably in a separate lab (if 
feasible). 

• No personnel shall perform work on a powered-up 
payload, unless that work is required to support the 
operation being conducted. Those I&T team 
personnel who must work in the vicinity of the 
payload should be notified of payload activation. 

Electrical I&T Practices — In addition to the recommended 
general practices, the following apply to personnel 

supporting electrical operations: 

• Minimize connector mates and demates whenever 

possible, to avoid having to reverify interfaces and 
to help mitigate against connector failure. The 
latter can also be accomplished by using connector 
savers (if repeated demates are anticipated), or 

simply by exercising judicious consideration prior 
to demating. For example, if possible, perform 
electrical measurements from a ground support 
equipment (GSE) interface rather than a flight one. 

• When using electrical test equipment, such as 

power supplies and break-out boxes, use proper 
leads and jumpers to minimize discontinuities and 
inadvertent shorts. If leads or jumpers are not 
available, fabricate new ones to support the job. 

• Label ail cables and connectors. This includes 
correct cable and connector information on all ends 
of flight and GSE harnesses, and temporary labels 
(e.g., tape) on test equipment when appropriate. 

• After mating GSE cables or test equipment, 

provide adequate strain-relief support to harnesses. 
For example, non-flight ty-raps can be used to 
temporarily secure cables to brackets or dollies. 

• When demating connectors on any flight or ground 
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equipment, grasp the connector, not the cable. 

• Cap unused connectors on flight cables, and on 
GSE when appropriate, using anti-static caps (if 
available). 

Formal Training — Beyond basic flight hardware handling 
practices are formal training courses for certification, such as 
electrostatic discharge (ESD) awareness, ordnance handling, 
soldering, crimping and harnessing. Those involved with 
flight hardware fabrication and handling must be certified, 
and I&T engineers should consider certification themselves 
in case their hands-on services are required. Flight 
certifications also provide the engineer with the knowledge 
necessary to evaluate proper flight hardware fabrication and 
handling performed by others. 

Ordnance Operations — Handling of ordnance is usually 
performed by the lead engineer or technician for the system 
using the ordnance. For example, in the case of Hitchhiker 
ejection systems, the carrier mechanical team usually 
retrieves NASA Standard Initiators (NSI’s) from the storage 
facility and installs them into the bolt cutter assemblies. 
Proper handling of ordnance includes utilizing wrist-stats, 
even when contacting hardware in which NSI’s are installed. 
Hardware should be tagged with ’’ordnance installed” signs 
or streamers. The hazardous operations area should be 
cordoned off, inside which only those directly involved with 
the operations may enter. 

While the actual ordnance operations are being performed, 
the I&T manager or task leader should monitor the 
immediate area for nonessential personnel or activities. If it 
takes yelling to get someone’s attention to prevent a 
hazardous situation, so be it; better this than to have a hand 
blown off by an explosive device like an NSI, 

Regardless of whether the ordnance system is flight or not, 
the individual handling the ordnance must be properly 
trained and certified to do so. Those performing operations 
with the ordnance system following integration (such as 
installing ami plugs) must also be certified in ESD 
awareness and pyrotechnic operations. Unfortunately, good 
courses for ordnance handling are difficult to find; the only 
pyrotechnic training covering operations for shuttle 
operations are offered by KSC. 

Troubleshooting Anomalies — All anomalies should be fully 
investigated and understood. However, it is recommended 
to start with a troubleshooting plan to proceed in an orderly 
manner and, for example, to avoid unnecessary violation of 
interfaces. 

Some rules of thumb for troubleshooting itself: 

• Avoid deactivation of the payload or instrument, or 
rebooting of software, until as much information as 
possible is obtained about the problem. 

• It is usually best to start troubleshooting the 
ground system first, and then those flight items 
which are least intrusive to the flight configuration. 

• Only one change to the flight or ground 
configurations should be made at a time, to help 
isolate the problem. 
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• Don’t assume that the released engineering 
accurately reflects the current hardware 
configuration. Drawings should simply be 
considered a troubleshooting tool. 

• As much detail as possible should be recorded in 
the logbook (or on the procedure), regardless of 
how insignificant it may seem. This data may 
prove useful later on, for example, to help 
determine the exact configuration at any point in 
the troubleshooting. 

• Notes and data should be recorded real-time, rather 
than reconstructed after the fact. 

Once a problem is isolated, consider deliberately repeating 
the problem (if safely possible), for conclusive proof. Every 
effort should be made to fully explain any anomalies, 
especially those which are intermittent. Any that are 
deemed ’’unexplained” may come back to haunt you. 

I&T Manager Communications 

With I&T Team — Communication among the I&T team is 
of utmost importance for the smooth and safe performance cf 
payload I&T. The focal point for this communication is the 
I&T manager, who is the single-point contact for payload 
I&T at both the development facility and launch site. In 
this capacity, the I&T manager can disseminate information 
regarding individual payload subsystems and customers 
among the entire I&T team. This role of the I&T manager 
also helps to avoid multiple requests for support and 
resources throughout I&T. 

It is the responsibility of the I&T manager to keep the team 
informed of I&T schedule and status on a regular basis. 
Conversely, to do his/her job effectively, the I&T manager 
must likewise be kept informed of any changes to the I&T 
schedule, and be notified of any delays or support conflicts 
as soon as possible. If updates for each subsystem are not 
periodically received, the I&T manager may need to “poll” 
the I&T team for status. 

Prior to a significant operation, such as a payload test 
procedure, a pretest briefing should be held with all 
participants. This short meeting, usually hosted by the task 
leader, includes: 

• Distribution of copies of the released procedure and 
any deviations (“devs”), from which participants 
can work or follow along; 

• Identification of key personnel and responsibilities, 
with task leader as primary contact for all 
operations; 

• Discussion of potential hazards and controls (e.g., 
emergency power down); 

Directing that no unrelated work is to be performed 
on the payload while power is applied. 

Finally, the good communication with the I&T team 
depends on the I&T manager’s openness to alternative 
suggestions, whether solicited or not. Personal opinion 
should take a back seat to “doing what makes sense.” 

With Payload Customers — Besides communication among 
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the I&T team, that with the payload customers is also 
important. Customers should be encouraged to 
communicate with the I&T manager on a regular basis, in 
an "open door" like policy. The I&T manager should be 
informed well in advance about any planned customer 
operations or requirements, and be notified as soon as 
possible regarding any unplanned activities. Again, 
customers should approach the I&T manager for any 
requests for support or I&T-related issues. 

In the case of KSC operations, customers should be 
reminded to go through the I&T manager for special 
requests to KSC. This approach helps to minimize 
redundant, multiple requests to KSC personnel and helps 
keep the I&T manager informed about customer operations. 

With KSC— As mentioned earlier, the I&T manager is 
considered the single-point contact for all integration and 
test activities at both GSFC and KSC. As such, the I&T 
manager must be kept informed of all carrier and experiment 
plans and activities. This will help ensure availability of 
resources, proper operational sequencing, and safe 
implementation. 

The Future Payload Manager (or FPM, formerly the 
“Launch Site Support Manager’*) is considered the I&T 
manager’s contact for communications with KSC. This 
communication path helps to minimize extraneous and 
erroneous communications. Of course, some technical 
details will still require direct discussion between specific 
discipline engineers. 

The I&T manager is usually in frequent contact with the 
FPM during the final weeks leading up to delivery to KSC. 
Part of this information exchange includes regular updates 
regarding the expected arrival date, as well as any unique 
support requirements. This allows the FPM to keep the 
KSC payload processing team (PPT) informed and therefore 
better prepared to receive the Hitchhiker payload and 
personnel. 

The I&T manager may also participate in weekly PPT 
meetings via telecon. However, since most of these 
meetings involve discussion of topics unrelated to secondary 
payloads, participation is usually optional for small payload 
teams. 

3. Process Documentation and 
Configuration Management 

Payload Project Configuration Management 

Scope — Even before the introduction of ISO-9000 
requirements, process documentation and configuration 
management (CM) has played an important part of NASA 
flight projects. Process documentation includes things like 
certification logs, as-run procedures, problem reports, and 
other “quality records.” Configuration management 
includes maintaining a system of as-built hardware and 
software configuration, including requirements, procedures 
and drawings. Compared to some larger projects, CM for 
small payloads should be a more streamlined and user- 
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friendly system, due to more limited resources. 

In the case of Hitchhiker, a CM office and Configuration 
Control Board (CCB) has been established to track 
configuration, release documentation, and process 
Configuration Change Requests (CCR’s). CCR’s are 
required for all changes to the baselined flight configuration. 
Verbal approval may be obtained prior to written approval 
for changes which can be “reversed,” that is, if the hardware 
can be restored to its original configuration if ultimately 
disapproved by the CCB. 

Each small payload project must decide to what extent CM 
will be established and enforced. However, some form of 
CM is advisable for accountability and tracking as-built 
configuration for all human spaceflight projects. 

I&T Considerations — Depending on the CM approach 
established by the small payload project, it is the 
responsibility of the I&T manager to ensure that: 

• All new hardware is fabricated to released drawings; 

• All modifications are documented and approved; 

• All operations are worked to a released plan, 
drawing, and/or procedure; 

• All as-run procedures are fully annotated and then 
maintained in an I&T logbook, for example; 

• All anomalies are documented and maintained in 
the I&T logbook. 

As an example of realistically tailoring documentation to the 
project’s needs. Hitchhiker has historically not recorded 
electrical connections and disconnections in a “mate/demate 
log.” This is primarily due to the streamlined 
documentation warranted by Class-D payload operations, 
and necessitated by the limited manpower available. In fact, 
despite the relatively large number of connection cycles over 
the years, functional testing of those electrical interfaces to 
be used for a particular flight is deemed sufficient for mission 
success. 

Nonconformances — Any nonconformances or anomalies 
encountered should be documented, to allow tracking as 
well as provide an historical record. The level and extent of 
problem documentation depends on the individual project. 
As mentioned earlier, any troubleshooting should be 
deliberate and well-documented. 

Once a corrective action is determined, this should also be 
documented by whatever mechanism has been established 
by the project (problem record, logbook, etc.). If a 
modification is required which affects released engineering 
drawings, this should also be formally documented. 

Customer “CM” 

Documentation — Although individual customers are not 
always bound by the payload project’s CM requirements, it 
is still important (particularly for flight safety) to ensure that 
the instrument as-built configuration is consistent with the 
documentation. For the purposes of I&T, accurate, 
organized, and complete documentation provides an 
invaluable source of information if troubleshooting becomes 
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necessary. 

For these reasons, instrument developers should keep logs 
and drawings showing the as-built configuration of their 
system. This documentation can help ensure that the 
payload safety review process, as well as I&T itself, 
proceeds smoothly. 

Documentation which is useful to maintain during the 
course of instrument development includes: 

• Test and assembly logs, including records of any 
anomalies and modifications; 

• Certificates of compliance for materials and 
components, including those provided by vendors; 

• Record of Mandatory Inspection Points (MIP’s) to 
verify safety items and as-built configuration; 

• Up-to-date mechanical drawings and electrical 
schematics, including fuse and wire sizes; 

• Parts and materials lists, with Material Safety Data 
Sheets (MSDS’s) for hazardous materials 
(hazmats); 

• Fastener certifications and logs, including torque 

levels; 

• Summary of open items or problems, if any, to be 
addressed following delivery to GSFC. 

The CCCR — Besides the as-built configuration and 
certification data mentioned, post-delivery configuration 
management of the instruments is also important. For 
example, customer hardware or software is sometimes 
modified following delivery in order to effect enhancements 
or correct problems. Such changes must be brought to the 
attention of payload project personnel to ensure that even 
seemingly benign modifications will not compromise flight 
safety or mission success. Since small payload projects 
generally do not maintain configuration of customer 
hardware or software, other means should be established to 
help identify and track customer changes. 

The SSPPO has instituted a process by which modifications 
by the customer can have greater visibility and review for 
potential impacts. Following delivery to GSFC, customers 
are requested to complete and submit a Customer 
Configuration Change Request (CCCR) for any changes to 
flight or non-flight hardware or software from that originally 
approved for use. Since the CCCR is used simply as a 
communication tool, it imposes no CM requirements on the 
customer. The sample form can be found in the SSPPO ’s 
“Customer Accommodations and Requirements 
Specifications” (CARS) document [4]. 

4. Payload Development 

Payload Carrier 

I&T Considerations — From the very beginning of payload 
carrier development, all aspects of I&T must be considered. 
Therefore, I&T personnel must participate in the design of 
new carrier systems, so that the final product design takes 
into account real-world integration issues. Experienced I&T 
input will help ensure that, once the new carrier is 
developed, it can be integrated as efficiently and safely as 
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possible. For example, test connector brackets are now 
installed on some Hitchhiker canisters to allow easier access 
for testing in the orbiter. 

An important point regarding design for electrical interface 
verification is that all final electrical connections must be 
verified for flight, either functionally or by continuity 
measurement. This means that interfaces which cannot be 
powered following final connection, such as arm plugs for 
ordnance circuits^ must be designed with a parallel test 
connector to allow verification that all circuits are intact after 
mating. 

Finally, all items to be handled in the orbiter, such as dust 
covers or safe/arm plugs, must be designed to be tetherable 
for handling, and secure when installed. In the case of one 
Hitchhiker payload, a customer’s dust cover was only 
pressure-fit onto an instrument aperture. When the payload 
was on the pad and a Titan was launched a few miles away, 
the cover vibrated loose, impacting and damaging another 
payload installed in the bay below. 

New Hardware Testing — Requirements for environmental 
testing of new components or subsystems should be clearly 
defined in a test plan. For SSPPO payloads, requirements 
are based on specifications defined in the Goddard 
Environmental Verification Specifications (GEVS) document 
[5] and the Shuttle “Core” ICD [6]. 

Environmental testing performed on new components or 
subsystems typically includes vibration and thermal- 
vacuum. In the case of Hitchhiker, the only environmental 
testing performed at the integrated payload level is 
electromagnetic compatibility (EMC). For payloads 
involving safety-critical circuits, all inhibits are enabled 
during environmental testing to ensure safety is maintained 
during worst-case conditions. 

For flight mechanical components being developed, 
pre integration fit-checking is recommended whenever 
possible. History has shown that, despite the best 
drawings, actual hardware may not always fit properly. 

Flight Hardware Reuse — The Hitchhiker project has the 
luxury of reusing the majority of its carrier hardware from 
mission-to-mission. Carrier components which already 
exist are selected for reflight, with fabrication of new 
hardware only as necessary. Existing hardware to be reused 
is obviously not required to undergo requalification testing. 
However, some hardware (such as limited-life items) must 
at a minimum be thoroughly inspected prior to reflight. 

In the case of Hitchhiker electronics assemblies, typically 
only those circuits to be used for the assigned mission are 
refurbished and tested. This includes replacing fuses and 
performing bench-level functional testing. Electrical 
harnesses are selected from an extensive "library” cf 
previously flown cables. Of course, as more payloads are 
flown, more cables become available from which to choose. 

Flight and Ground Software — Flight software for small 
shuttle payloads may include C&DH software internal to the 
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payload itself, or that installed as part of the Payload and 
General Support Computer (PGSC) flight load. Verification 
usually involves testing with the hardware (either a 
simulator or flight). The payload-unique flight software is 
then sent to JSC to be included in the PGSC flight load for 
the mission. 

Although initial PGSC software testing may be conducted 
with a laptop simulator, final testing with the integrated 
payload should be performed using a JSC-provided, flight- 
like PGSC. PGSC loaners are requested from JSC via a 
Request For Support (RFS) form, for periods of two weeks 
at a time. 

If a ground command and telemetry system is being used to 
support payload l&T, any displays and procedures are 
(ideally) baselined by the start of testing. Periodic training 
for test team personnel is recommended. Utilizing the same 
ground system for both I&T and mission operations, as is 
done for Hitchhiker, is obviously preferable and most 
efficient. 

Customer Instrument 

Customer-to-Carrier Interfaces and Requirementss — Small 
payload customer interfaces and requirements, including 
those for ground operations support, must be clearly 
identified and well-defined in advance. These are usually 
specified in a payload-to-customer ICD, based on a customer 
requirements document. Details of mechanical and electrical 
interfaces are usually included in drawings referenced in each 
ICD. 


Some examples of requirements included in the payload-to- 
customer ICD (or on referenced drawings) are: 

• Electrical interfaces: command, telemetry, video, 

recording, PGSC; 

• Mechanical interfaces: mounting locations, 

orientation, handling; 

• Thermal interfaces: heaters, blankets, mission 

thermal modeling; 

• Ground support equipment: GSE, slings, and 

containers; 

• Servicing: purging, battery charging, accessibility; 

• Safety: hazmats, operations; 

• Misc. I&T issues: cleanliness, tethering, 

temperature & humidity limits, radiation 

sensitivity (e.g., x-rays). 

Those requirements involving KSC operations are included 
in PIP Annex 8 (Launch Site Support Plan, or LSSP), and 
possibly Annex 9 (Operations and Maintenance 
Requirements and Specifications Document, or OMRSD) if 
any involve interface verification, unique environmental 
constraints, or stand-alone payload operations in the orbiter. 

The latter include testing, battery top-charging, cover 
removals, etc. It is important that a customer’s 
requirements are clearly understood as either mandatory, or 
simply recommended or ’’highly desired." Customers may 
need to be reminded that small shuttle payloads are usually 
“secondary” payloads, and as such have little clout when it 
comes to driving KSC operations such as payload-bay door 

10/15/01 


opening at the pad. 

I&T Considerations — As with the payload carrier, I&T 
issues related to. the customer should be considered during 
the development phase. First, customer hardware design 
and flight configuration should be formally documented on 
released engineering drawings. This is especially important 
for those components which could be integrated with the 
carrier in more than one orientation. 

For customer hardware requiring late access in the orbiter, 
accessibility must be considered in the design phase, as 
mentioned earlier for carrier hardware design. For example, 
connectors for battery top-charging, inhibit verification, and 
other prelaunch operations should be accessible from step- 
ups, “pic” boards, or platforms. The same is true for 
"remove-before-flight" items such as lens covers and drag-on 
purge lines. Use of the Orbiter Processing Facility (OPF) 
“bridge bucket” for access to the payload is strongly 
discouraged, since bucket operations depend on the 
availability of both the bucket and an operator. 

Preintegration Testing — It is strongly recommended that 
customers complete all environmental testing prior to 
delivery to the payload organization for final flight 
integration. Once the entire payload is integrated, it is 
difficult or impossible to correct any problems or shuttle 
ICD exceedances, such as might be discovered during EMC 
testing. Not only will the customer hardware be virtually 
inaccessible within the integrated payload, but the KSC 
delivery schedule may not allow time to modify hardware 
late in the flow. 

Besides the usual qualification and acceptance testing, 
customer preintegration testing with the carrier is also 
recommended. Preintegration testing provides customers an 
opportunity to verify function of both flight and ground 
system interfaces well in advance of flight integration. It is 
usually performed early enough to allow time to make any 
modifications, if necessary, prior to final delivery. 

Preintegration tests can be performed using customer 
prototype or flight hardware (or software) in development. 
Any testing of the customer interfaces with the carrier prior 
to delivery is helpful, even if just to check ground test 
system interfaces. 

Preintegration testing also provides an opportunity to verify 
the accuracy of procedures prior to final delivery. In any 
case, performing the test using a written procedure not only 
serves as a dry-run of the flight integration procedure, but 
also documents the as-run operation for future reference. 

5. Payload Integration 

Carrier Integration Sequence 

Integration of individual payload components should be 
performed in the most logical sequence. However, the 
implementation of a logical integration sequence depends on 
several factors, including the availability of hardware, the 
accessibility of components once integrated, and functional 
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interdependence. 

Integration of payload carrier components should be 
completed prior to interfacing with customer hardware. I&T 
should be performed in a sequence which allows ease of 
accessibility for certain operations (such electrical 
measurements), yet also minimizes risk to the flight 
hardware. Routing of harnesses for flight should be 
performed only after all functional testing of the particular 
end item is complete. Thermal blankets may or may not 
have to be installed prior to final flight connections, 
depending on whether they have been designed to allow 
installation over connected cables. 

Regardless of the I&T sequence, the I&T manager must 
understand all the subtle requirements of the I&T flow. He 
or she should make the I&T flow clear to the I&T team (via 
meetings, schedules, I&T plan, etc.), yet remain open to 
suggestions of alternatives from other team members. 
Again, the important point is to do what makes sense. 

Customer I&T 

Customer Predelivery Preparations — Customer procedures 
(planned and contingency) required for I&T should be 
submitted to the payload organization no later than one 
month prior to delivery. This will ensure adequate time for 
review and modification (if necessary) prior to customer 
arrival. Customers should be strongly encouraged to 
perform dry runs of the procedures they plan to perform 
following delivery. This will not only provide 
familiarization with the procedures themselves, but may also 
help reveal problems or discrepancies with the hardware or 
software which may need to be addressed. 

Customers should be advised to avoid last-minute design 
changes to hardware or software. This is particularly 
important with respect to changes involving mechanical and 
electrical interfaces to the carrier. This also applies to 
customer commands required to be sent during the payload- 
to-orbiter interface verification test (IVT), since these will 
have been previously defined in the PIP Annex 4 
(Command and Data Annex). If late modifications to 
hardware or software are deemed necessary, then the as-built 
documentation must be updated accordingly, including any 
inputs to the safety data packages. 

The customer-to-carrier ICD should also reflect the latest 
payload interface and I&T requirements. Any last-minute 
changes to the ICD should be approved by the payload 
carrier and customer prior to customer hardware delivery. 

To support payload-level I&T, customers should be 
reminded to bring their instrument test and assembly logs, 
schematics, unique tools, test equipment, and consumables. 

Customers should also bring flight-qualified spares for 
critical components, as these may have a long-lead delivery 
time. 

Customer Delivery— \Jn less prior arrangements have been 
agreed to, the customer is expected to deliver the instrument 
and GSE ready for integration with the payload carrier. The 


only operations to perform prior to carrier I&T are typically 
receiving and inspection, and any postship functional testing 
of the instrument 

Shortly after the customer arrives, a “turn-over” meeting 
with the customer and I&T team is held. Some I&T- 
related items which should be addressed during the meeting 
are: 

• General customer status/summary; 

• Open customer work to be performed (before or after 
start of carrier integration); 

• Anomalies (explained or unexplained); 

* Deviations to procedures previously identified 
(planned or contingency); 

* Distribution of customer and payload procedures; 

* Status of carrier flight and ground systems; 

* Plan for integration and test: schedule, location, 

personnel, hazards; 

• Unique customer requirements, if any (alignment, 
purge, calibration, charging, etc.); 

* Customer support area (i.e., office space); 

• Customer responsibility for shipping, handling, 
and storage of their own equipment. 

Customer-to-Carrier I&T— Following completion of any 
post-ship stand-alone functional testing, the customer 
hardware is mechanically integrated with the payload carrier. 

Prior to electrical connection to the carrier power and 
C&DH subsystems, resistance measurements should be 
taken at the customer interface to verify proper continuity 
and isolation, as applicable. Following electrical 
connections for flight, a functional test should be performed. 
Since the purpose of this test is to ensure the final flight 
mates, it may be abbreviated if a full functional w r as 
performed during initial electrical I&T. 

It is advisable to restrict activation of individual instruments 
to times when there is a customer representative present to 
monitor instrument status. 

Payload-Level I&T 

Final Integration — After all hardware is installed, the 
payload should be configured as close as possible to flight. 
This includes securing all thermal blankets and cable 
harnesses. It may be desirable to delay installation of lock- 
wiring and staking, in case removal of hardware is required 
for whatever reason. 

IVT Simulations — To ensure that the orbiter IVT sequence 
is correct, as well as familiarize the team with the IVT 
procedure, IVT simulations are conducted. These sims are 
performed with the payload in the flight configuration, with 
the latest version (or draft) of the IVT procedure. Generally, 
IVT sims are perfonned upon completion of payload 
integration at the carrier facility, and then upon completion 
of Payload Processing Facility (PPF) testing at KSC just 
prior to orbiter integration. 

For those payloads utilizing a PGSC, it is important to use 
the latest mission software available from JSC. However, 
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the “training load” software is usually not available until L- 
110 days, and the final flight load is not released until 
approximately L-40 days. 

Since the PGSC software used during the IVT sim may not 
be the final version, JSC should notify the payload of any 
changes to the flight load following initial release. This 
notification should allow enough time for the payload- 
unique software to be modified and tested, if necessary, prior 
to the orbiter IVT. 

All individuals who plan to support the actual orbiter IVT 
should participate in the IVT sims. This includes members 
of the I&T team as well as any customers involved. Having 
the same people for both tests is especially important for 
subjective verifications, such as those for closed-circuit 
television (CCTV) images. It also helps ensure that 
everyone is familiar with the procedure and associated 
verifications prior to the orbiter IVT. 

If crew is available, such as a payload specialist, then he/she 
should also participate in the IVT sims for the 
familiarization opportunity. In this case, the crew should be 
kept informed of the test schedule, which may need to be 
adjusted to accommodate availability. 

Transfer to EMC — Upon completion of customer-to-carrier 
integration, the payload is transferred to an EMC test 
facility. Performing EMC testing on the payload in flight 
configuration is important to accurately test for emissions 
and susceptibility. Testing is based on the latest EMC 
limits identified in the shuttle “core” ICD. 

For payloads involving safety-critical circuits, all inhibits 
must be enabled during EMC testing to verify no 
susceptibility. For example, any ordnance should be 
installed and connected, and the system fully armed. 
Ordnance integrity should be verified at regular intervals 
during susceptibility testing (such as the end of each test 
day), to limit the amount of retest required if susceptibility 
is discovered. 

EMC test data which indicates any exceedances is provided 
to JSC for review. Exceedances which are approved for 
flight are eventually documented in the payload-to-orbiter 
ICD. Those not approved are mitigated through redesign 
(such as incorporation of electromagnetic interference filters) 
or operationally (e.g., not activating the emissions- 
producing hardware). 

Telemetry Recording — If a small shuttle payload has any 
telemetry interfaces, data should be recorded during I&T for 
later playback during mission simulations. Ideally, this 
telemetry reflects payload configurations expected during the 
mission, and therefore requires that each of the subsystems 
and instruments be operated in various on-orbit modes. 

For any ground data GSE to be used both during I&T and 
the mission itself, two sets are recommended. This will 
allow support of mission sims during prelaunch I&T, as 
well as provide an back-up set if the prime has a failure. 
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6. Preparations for Launch Site Operations 

Documentation 

Payload Procedures — Although the format for payload 
procedures is generally up to the payload provider, it is 
preferable to have payload procedures in the same format as 
KSC procedures. This helps not only to translate to KSC 
format if needed for KSC work authorization documents 
(WAD’s), but also helps familiarize the payload team with 
the KSC format. 

Hazardous procedures usually require KSC-specific wording 
and formatting. The distinction between hazardous and 
non-hazardous procedures is outlined in KHB- 1700.7 [7], 
with which the I&T team should be familiar. 

Currently, all payload procedures (planned and contingency) 
are due to KSC 45 days prior to first use. 

KSC Documentation — Like payload procedures, KSC 
should provide to the payload for review drafts of all 
documentation related to processing the payload. This 
includes the Launch Site Support Plan (LSSP), Program 
Requirements Document (PRD), Test Preparation Sheets 
(TPS’s), Operations and Maintenance Instructions (OMI’s), 
and prelaunch switch lists, as applicable. All of these must 
be reviewed thoroughly for accuracy during the draft phase, 
to avoid having to mod or dev a document after it is 
released. As with payload inputs to KSC, procedures 
should be submitted to the payload for review 45 days prior 
to first use. 

For procedures involving payload connections or 
disconnections, explicit steps and respective "OK’s” for each 
mate/demate should be included. A table or checklist with 
each mate/demate, which can then be signed-off when 
completed, may also be helpful. Each step should be 
referenced in only one procedure (either payload or KSC), to 
avoid confusion regarding who should perform the operation 
and whether it has been completed. 

Even before the KSC procedures are written, payload 
requirements must be specified in the LSSP and OMRSD. 
Facility, consumable, and other support requirements are 
included in the PRD. Also, any hazardous operations 
requiring KSC support (e.g., pad clears, RF silence, etc.) 
should be explicitly identified in the LSSP and/or PRD. 

Orbiter Documentation — Usually before the Cargo 

Integration Review (CIR), approximately one-year prior to 
launch, the payload provides initial inputs to such 
programmatic documentation as the PIP and annexes, 
detailed orbiter schematics, and the IRD. The latter is most 
important for side-mounted payloads, and should identify 
departure lengths for any payload-to-payload cables which 
are fabricated by the payload provider and sent to KSC for 
preinstallation into the orbiter. The I&T manager should 
thoroughly review this documentation for accuracy. 

In the case of the PIP Annex 4, confirmation of command 
bit patterns is especially important. This is because KSC 

9 


uses the Command and Data Annex to generate Payload 
Signal Processor (PSP) commands sent via the Launch 
Processing System (LPS) during the orbiter IVT. Any 
discrepancies are difficult to identify and correct while the 
IVT is in progress. Therefore, the command tables should 
be thoroughly reviewed for accuracy prior to Annex 4 
release. 

The OMRSD is used to ensure that a requirement is 
formally levied on KSC. Compared to the LSSP, the 
OMRSD affords greater visibility and tracking, especially in 
the orbiter world. Also, keep in mind that the OMRSD is 
meant to specify what requirements need to be fulfilled, not 
how they are to be implemented — those details are left for 
the procedures. 

As orbiter integration becomes imminent, tech orders 
(TO’s) will be generated by orbiter engineering to document 
the details necessary to integrate a particular payload. It is 
important that the individual discipline engineers review the 
TO’s to ensure technical accuracy, well in advance of orbiter 
integration. 

Personnel Training and Badging 

Note : As of the date of paper submission, security 

requirements at NASA facilities were being revised. It is 
recommended that the I&T manager verify the latest KSC 
security requirements, and ensure payload team compliance 
prior to payload delivery. 

Types of Badging — All payload personnel, NASA and non- 
NASA, must be properly trained and badged to enter and 
work in facilities at KSC. Two types of badging are in force 
at Kennedy. The first allows access onto government 
property, and basically requires a either a permanent picture 
badge or a temporary "machine pass." The second allows 
entry into designated areas and facilities, and requires an area 
permit which can be either permanent (for which a Personnel 
Access Control Accountability System, or PACAS, badge 
is issued) or temporary (for which a Temporary Area 
Authorization, or TAA, is issued). The latter can be either 
for escorted or unescorted access. 

It is recommended that the entire payload support team 
obtain unescorted access, not only since they will probably 
require periodic, long-term access to KSC facilities, but also 
because they can help escort customers if necessary. For 
payload customers, escorted badging is usually sufficient 
since most are only one-time visitors and no special training 
is required in this case. For those customers with 
anticipated long-term or multiple visits to KSC, unescorted 
access is recommended. 

Training Requirements — Those requiring unescorted access 
to KSC facilities must also be trained in emergency egress, 
including use of the Emergency Life Support Apparatus 
(ELSA) and the respective facility "walk-downs" (usually on 
video). General safety videos must also be viewed, 
including: Ammonia Hazard, Pad Debris Damage, Space 

Shuttle Safety, and General Processing Safety. 


Unescorted access also requires that a full Personnel 
Reliability Profile (PRP) security investigation on the 
individual be conducted. Unfortunately, the process is quite 
lengthy, requiring personal history details submitted usually 
a year in advance. Although one’s PRP approval can be 
renewed, if it lapses for an extended period (i.e., over a year 
or so), then the entire investigation process must be 
reperformed. 

In addition, anyone requiring access to elevated platforms 
must be trained in fall protection, which involves use of 
body harnesses tethered to support structures. Anyone 
involved in use of hazardous materials (including solvents 
and staking compounds) must be trained in "hazardous 
waste handling." Finally, anyone requiring access to the 
orbiter must view the midbody and crew module 
familiarization; it is required that these videos be viewed at 
KSC for training to be considered valid. 

Training/certifications must be kept up-to-date, such that 
personnel are certified for the duration of scheduled 
operations. As much training as possible should be 
completed before start of KSC operations, so time at the 
Cape can be used most effectively. Major operations or 
meetings should not be rescheduled to accommodate 
training. 

Shipping 

Arrangements — About a year before going to KSC, the I&T 
manager (or designee) should initiate DOT approval for 
shipment. Requests must begin this early to allow for DOT 
processing time, especially if there are hazmats involved, 
such as hazardous chemicals, radioactive substances or 
explosives. If shipping via highway is ultimately denied, 
alternatives modes of transport include plane and barge. 
The latter was necessary to ship CAPL-1 Hitchhiker (STS- 
60), due to its relatively large quantity of ammonia. Since 
then, Goddard has obtained a global DOT exemption for 
shipping up to 0.25 pounds of ammonia per heat pipe. 

Some other issues which need to be addressed prior to 
shipment include: 

• Generation of shipping list, including up-to-date 
MSDS’s and hazmat checklist; 

• Contracting and scheduling of the truck; 

• Arranging for truck driver badging at KSC, and 
providing specific directions to driver; 

• Generation of shipper, and verifying against items 
loaded onto truck. 

More on Hazmats — All hazardous materials must be 
identified in advance, for GSFC and KSC processing safety, 
as well as shipment. Those items which should be 
assumed hazardous until proven innocent include: 
chemicals, gases, radioactive materials, and ordnance. 
Small, commercial, off-the-shelf batteries are not considered 
hazmat items. 

Hazmats contained within payloads which have been 
approved for shipment from GSFC to KSC must again be 
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properly classified as a hazardous material on shipper, with 
an MSDS included. Hand-carrying of hazmats is 
prohibited. Special requirements may also apply for 
radioactive materials. 

Loading and Shipment— Although shipping requirements 
depend on such things as payload size and sensitivity, the 
payload and GSE can usually be shipped in an 
environmentally controlled moving van. 

The actual day of shipment to KSC depends on the amount 
of time required for post- ship I&T prior to orbiter 
integration. To take most advantage of the work week at 
KSC, it is usually advantageous to ship on a Saturday for 
arrival first-thing Monday morning. The FPM should be 
contacted to arrange for entrance of the truck and personnel 
onto KSC. 

Finally, it is traditional to have plenty of payload stickers or 
other “goodies” on-hand for the movers and any other 
support personnel. 

Miscellaneous Preship Considerations 

GSE Certification— Mechanical ground support equipment 
(MGSE), such as lifting slings, must be proof-loaded and 
certified to lift flight hardware. This certification is valid for 
only one year, which is usually sufficient to support both 
prelaunch and postlanding operations for small payloads. 
Therefore, it is desirable to have the MGSE proof-loaded as 
late as possible just prior to shipping, with a couple of 
weeks added for contingency. 

Also, electronic test equipment (such as meters) should be 
calibrated prior to shipment. Since meters and other 

electrical GSE (EGSE) are readily available at KSC, last- 
minute calibration of these is not as critical as for MGSE. 

Payload Bay Cabling— Some Hitchhiker cables, such as 
“cross-bay” cables, are installed by KSC into the payload 
bay prior to payload installation. These should be shipped 
down to KSC well in advance of being required for 
integration into the orbiter. If time allows, the cables 
should be transported with the payload; otherwise, they 
must be shipped in advance (along with the flight 
certification documentation). Unless another contact is 
designated, the FPM can be the point-of-contact for 
receiving the cables at KSC. 

Preship and Configuration Reviews — For Hitchhiker, an 
“in-house” preship review is conducted prior to shipment to 
KSC, to verify that there are no hardware configuration 
issues, or nonconformances or anomalies to be addressed. 
Ideally, the preship review is scheduled immediately 
following the EMC test so any exceedances can also be 
presented. The review is also the last opportunity to verify 
all documentation is up-to-date: certification logs, problem 
records, procedures, ground safety verification items, etc. 

Also prior to the preship review, a review is conducted to 
identify any configuration discrepancies between the 


hardware and orbiter documentation. Conducting this 
configuration review before shipment allows enough time to 
correct any discrepancies before orbiter integration. A final 
survey is conducted at the PPF, just prior to transfer to the 
orbiter, to cover any items integrated in the field. 

Things to Bring — The following is a non-exhaustive list of 
items which the I&T manager should bring (or arrange to be 
shipped) to KSC: 

• Latest versions of procedures (payload stand-alone 
or KSC), including any redlines; 

• Latest payload drawings, including all cable 
assembly drawings and carrier schematics; 

• Excerpts from the pay load- to-orbiter ICD, 
especially electrical pin-outs; 

• Latest Annex 4, OMRSD, LSSP, PRD, and IRD 
(if applicable); 

• Certification logs and as-run copies of procedures 
performed during payload I&T at the development 
facility; 

• List of key contacts at home and KSC (KSC 
Phonebook may be obtained via the FPM); 

• Badges (picture and KSC Area Permit) and any 
certification cards; 

• Beeper, if deemed necessary; 

• Stickers, pins, or patches, for KSC support 
personnel. 

7. Prelaunch Operations 

General 

The I&T Manager's Role at KSC — While at KSC, the I&T 
manager fulfills several functions. First, he/she continues to 
be the focal point for payload I&T operations. The I&T 
manager works closely with the FPM, through whom KSC 
support and resources are requested. 

Second, the I&T manager serves as the payload test 
conductor (or TC, not to be confused with KSC’s PTC). 
As such, the I&T manager is the primary payload contact 
during the orbiter IVT and other integrated operations. 

Third, the I&T manager also has the role of launch site 
safety representative for the payload. Therefore, he/she must 
be familiar with all safety issues associated with processing 
the payload at KSC. 

Finally, the I&T manager has payload signature authority 
for approval of KSC WAD’s and sign-off of as-run 
procedures. In this capacity, he/she may also sign-off on the 
payload closeouts for flight. 

Miscellaneous I&T Considerations — Following arrival at 
KSC, daily I&T meetings with a summary of operations for 
the week are usually helpful. Depending on the number of 
participants and space available, these can be relatively 
informal, stand-up meetings with the team. Pretask 
briefings, especially for major tests and hazardous ops, 
should be considered mandatory. KSC personnel who are 
involved in the operations should also attend. 
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Any overtime, whether it be on a daily or weekly basis, 
should be coordinated through KSC and payload 
management in order to comply with work restrictions. 
More importantly, personnel fatigue increases the risk of 
accidental injuries or damage to flight hardware. Any 
extension or rescheduling of operations should be decided 
upon with due consideration to the payload I&T team, 
which is typically ’’single-string.” 

Ordnance Operations— During testing and arming of 
ordnance (such as NSI’s) in the orbiter, the I&T manager 
must ensure that the operation has been identified as a 
hazardous ordnance operation. This includes scheduling 
RF-silence and requesting a local clear area (typically 10-feet 
from the hardware). Unless KSC requires it, an entire ’’pad 
clear” during ordnance operations is not necessary; a local 
clear is sufficient, with only a cordoned-off area in the 
immediate vicinity of the operation. RF-silence and clear 
area should be called out in the associated WAD. 

The KSC payload ops representative is responsible for 
ensuring that other personnel are notified about hazardous 
operations in the clear area. As during all ordnance 
operations, the area should be monitored for unauthorized 
entry and questionable activities. Finally, as mentioned 
earlier, those directly involved with handling ordnance or 
systems connected to ordnance must be trained and certified. 

Data Transfer — Occasionally, data must be transferred from 
the payload organization to KSC. This data includes final 
payload weight and center-of- gravity (c.g.), and that required 
for safety verifications and OMRSD requirements. 

Since there is no formal mechanism to handle data transfer 
between the payload and KSC, it is recommended that the 
payload develop a form similar to SSPPO’s T 'GSFC Data 
Transfer Form.” A copy of this form may be obtained from 
the SSPPO CM Office at GSFC; see the SSPPO website 
(http://sspp.gsfc.nasa.gov) for contact information. 

Likewise, as-run data from KSC WAD’s must sometimes 
be transferred from KSC to the payload. Unfortunately, 
there is no easy mechanism currently in place to transfer 
infonnation to the payload. In this case, it behooves the 
I&T manager to request any required KSC data via the 
LSSP. At a minimum, KSC should be provided with 
advance notice that the as-run data will be needed. 

Customer Access to Orbiter Facilities — Understandably, 
many payload customers may want to tour the various 
orbiter integration facilities (OIF’s), as well as the orbiter 
itself. This may be acceptable during a break in I&T, for 
example, or with only a couple of visitors. However, 
during critical integrated operations, such as orbiter 
installation or TVT, visitors not involved with the operation 
itself should not be permitted in the area. 

This is an even greater concern if a large number of 
customers (e.g., more than a couple) want to tour 
simultaneously. Instead, a separate tour when things are not 
as busy is recommended. Finally, unless there is sufficient 
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justification, no visitors are allowed inside the orbiter crew 
compartment. 

Operational Responsibilities at KSC— Depending on the 
nature of the operation involving shuttle payloads, either 
KSC or the payload has primary responsibility, with the 
other acting in a support role. KSC personnel have primary 
responsibility for performing most of the payload-to-orbiter 
integration operations. The payload representatives are 


responsible for performing those operations that involve 
payload-to-payload interfaces. These include not only 
payload flight interfaces, but nonflight ones such as test 
connectors for payload GSE. 

Here is a summary of general categories of operations and 
the primary responsible party for each: 

Primary 

Operation Responsibility 

Payload operations at the payload 
processing facility 

Payload 

Integration and deintegration involving 
payload-to-orbiter interfaces 

KSC 

Integration and deintegration during 
orbiter operations involving payload-to- 
payload interfaces 

Payload 

Payload testing involving payload-to- 
orbiter interfaces 

KSC 

Payload testing during orbiter operations 
involving PGSC or payload-to-GSE 
interfaces 

Payload 

Payload close-outs and postlanding 
operations involving direct contact with 
the payload 

Payload 


Postship Operations at the PPF 

Responsibilities at the PPF — Since operations at the 
payload processing facility (PPF) are off-line and stand- 
alone, the payload shall have the primary responsibility for 
performing this work. Generally, this includes prelaunch 
functional testing, payload preparations for orbiter 
integration, and any postflight operations prior to ship back 
to the home facility. 

KSC personnel are responsible for providing payload 
support and resources, as defined in the LSSP and PRD. 

Facilities — There are several facilities at KSC which are 
used as PPF’s for small payloads, including the Multi- 
Payload Processing Facility (MPPF), Space Station 
Processing Facility (SSPF), and Multi-Operations Support 
Building (MOSB). Historically, even off-site facilities (such 
as the Astrotech and SpaceHab buildings) have also been 
used as PPF’s prior to orbiter integration. Each facility 
requires separate familiarization training for access, as well 
as hands-on training for crane operation. 
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In recent years, the MPPF has been used for small shuttle 
payloads. The relative isolation of the MPPF affords users a 
certain level of autonomy. For example, payload 
technicians can be trained and certified to operate the MPPF 
crane. However, one drawback is that the MPPF is still 
considered a secure area and requires proper badging for 
access. 

If the SSPF is used, several points should be considered. 
First, the payload should be cordoned-off if not in a separate, 
secure area. Second, only KSC technicians are qualified to 
operate the overhead bridge cranes in the high-bay, so at 
least two KSC crane operators must support major lifts. 
Third, the proximity to KSC payload personnel helps in 
obtaining KSC support resources, yet also invites more 
intense scrutiny. Finally, office space in the SSPF is 
usually a premium, so small payload representatives may be 
relegated to remote locations. 

Receiving, Inspection, and Set-Up — Following arrival at the 
PPF, the payload and GSE are off-loaded from the truck, 
usually in the reverse order from loading. For flight 
hardware on small dollies, only hydraulic lift gates and fork- 
lifts may be used to unload. Use of truck platforms 
supported by chains is prohibited, since these have failed in 
the past (CryoHP Hitchhiker on STS-53), resulting in 
damage to the dolly and potential damage to the payload. 

If an elevated truck lock is unavailable, off-loading of cross- 
bay payload hardware has been performed using a 
combination of flatbed truck and portable crane. However, 
the use of roll-backs (or “Jerr-Dans”) has more recently been 
approved by KSC safety for off-loading large payloads. One 
issue which has come up in the past (regarding 
commercially rented roll-backs) is proof-loading of the cable 
used to hoist the payload onto the flatbed. However, this 
issue is reportedly no longer considered a safety issue. 

As the hardware is off-loaded, the individual who 
coordinated the shipping from the home facility verifies all 
hardware has been received and signs-off the bill-of-lading. 
After unloading, the flight hardware and GSE are usually 
rolled into an intermediate truck-lock area for unpacking and 
cleaning. Once inside the main cleanroom, the hardware is 
configured for post-ship testing and any additional 
integration required before transfer to the orbiter. 

Mechanical Integration — Depending on the type of payload, 
off-line mechanical integration at the PPF can be relatively 
simple or complex. For example, side-mounted payloads 
typically remain on dollies until orbiter integration. The 
price for this simplicity is paid during orbiter integration, 
when individual components must then be mounted and 
connected sequentially. 

For larger payloads, such as cross-bay Mission-Peculiar 
Equipment Support Structure (MPESS) bridges, PPF 
operations may require more mechanical integration. There 
may also be some instruments which are shipped on dollies 
separately, which would then have to be installed at the 
PPF. 


Electrical I&T— Once the payload is set up and connected 
to the EGSE, post-ship functional testing may commence. 
This includes activation of the carrier and all instruments, 
depending on customer support available. 

Usually, the final test performed at the PPF is a final IVT 
sim. Like the sim performed prior to shipment, the test at 
Kennedy is based on the IVT OMI, except this is the final 
released procedure to be run during the orbiter IVT. 

If the IVT involves using a PGSC, the payload (i.e., the 
I&T manager) is again responsible for obtaining a PGSC 
loaner from JSC. However, this last sim should be run 
using the latest flight software load from JSC, not only to 
verify software compatibility but to verify the orbiter IVT 
sequences with the released OMI. 

Unfortunately, the final flight load is usually unavailable for 
the IVT sim or even the IVT itself. However, as mentioned 
earlier, JSC should at least notify the payload organization 
of any changes to the mission software, to avoid surprises 
either during the IVT or on orbit. There should also be a 
mutually agreed-upon limit to the extent of any changes to 
the JSC flight load, to ensure the payload-unique software 
will not be affected. 

Upon completion of electrical I&T, any customer GSE can 
be packed for shipment to the Payload Operations Control 
Center (POCC), if needed to support the mission, or left at 
KSC if required to support the IVT. 

Transfer to Orbiter 

Preparations for Transfer — As mentioned earlier, a final 
configuration review is performed by a payload 
representative at the PPF. This is usually perfonned just 
prior to transfer to the orbiter. Although this check will 
have been perfonned just prior to shipment to KSC, this 
last-minute verification is to check the final flight 
configuration following PPF operations. 

A Vehicle Integration Test Team (VITT) representative 
usually performs the sharp-edge inspection; any areas of 
concern must be addressed prior to payload closeout for 
transfer. A contamination inspection is also performed, with 
any required cleaning supported by payload mechanical and 
thermal technicians. In general, the cleaner the payload is 
prior to transfer to the orbiter, the cleaner it will be on orbit. 

Transfer from PPF— After all off-line operations are 
complete, a final weighing of the payload is usually 
performed prior to transfer and the data is provided to KSC. 
The payload is then either double- wrapped (in the case of 
side-mounted payloads) or loaded into the transport canister 
(cross-bay payloads). 

For lifting larger payloads, KSC’s Integrated Partial 
Payload Lifting Assembly (IPPLA) is the MGSE of choice 
since it allows for c.g. adjustment. However, if the IPPLA 
is used, prelift inspections of both the bridge trunnions and 
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IPPLA trunnion supports are recommended to ensure no 
damage will be incurred. 

Occasionally, customers require a continuous drag-on purge 
for their instruments. This may be accommodated on a 
case-by-case basis. Otherwise, periodic interruptions of the 
purge may be necessary during transfer. 

CITE Testing— The horizontal CITE stand is a high-fidelity 
orbiter avionics simulator located in the SSPF. The 
purpose of CITE is to verify new payload electrical interfaces 
to the orbiter, prior to orbiter integration. 

Reusable payload carriers such as Hitchhikers are typically 
exempt from CITE testing, since electrical interfaces to the 
orbiter usually do not change from mission to mission. 
However, since CITE is required by default, KSC conducts 
a "CITE bypass study" to assess whether the test is actually 
necessary. 

The CITE IVT procedure is basically the same as the 
orbiter IVT, and is a good dry-run for the final orbiter test. 
A CITE test typically adds about a month to the prelaunch 
flow, including transfer operations. 

Orbiter Integration 

I&T Responsibilities at the OIF — KSC shall have the 
primary responsibility for integration (and de-integration) 
involving pay load-to-orb iter interfaces. This includes 
payload installation into (and removal from) the orbiter, as 
well as connection (and disconnection) of payload-to-orbiter 
interfaces. It also includes installation (but not connection) 
and removal (but not disconnection) of any payload-to- 
payload cable harnesses which must be routed within the 
payload bay structure. The payload is responsible for 
providing support for such operations, as required. 

The payload shall be responsible for performing integration 
(and de-integration) involving payload-to-payload interfaces 
during orbiter operations. This includes installation (and 
removal) of payload components, such as remove-before- 
flight items, drag-on purges, and payload-to-payload 
electrical connections. It also includes connection (and 
disconnection) of any payload-to-payload cable harnessing 
which are routed within the payload bay structure. KSC is 
responsible for providing support for such operations, such 
as platforms or bridge-bucket support for payload customer 
access. 

During integrated orbiter operations, KSC shall be 
responsible for performing payload testing involving 
payload-to-orbiter interfaces. This includes tests such as the 
payload-to-orbiter IVT and other integrated procedures 
involving payload activation via orbiter power. The 
payload provides test support for any integrated procedures 
requiring payload activation. 

The payload shall be responsible for performing all stand- 
alone operations involving payload-provided ground support 
equipment (GSE). This includes tests such as the payload- 
to-orbiter IVT and other integrated procedures involving 
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payload activation. It also includes tests involving payload 
activation via stand-alone power supplies or internal 
batteries, i.e., not requiring orbiter activation. KSC 
provides support for payload testing, as required. 

PGSC Operations — As mentioned above, KSC has primary 
responsibility for performing those operations involving 
payload-to-orbiter interfaces, and the payload performs 
operations on payload-to-payload interfaces. However, there 
are other interfaces for which the responsible party is less 
clearly defined. A case in point is when a payload-provided 
PGSC is being used during orbiter integrated operations. 
This includes tests such as the payload-to-orbiter IVT and 
other procedures involving payload activation. 

Such operations involving the PGSC and payload-provided 
software should be conducted by payload representatives, 
rather than KSC personnel, for two significant reasons. 
First, since the payload provides the PGSC for IVT, the 
payload is ultimately responsible for it. 

Second, since the payload customer also provides any 
payload-unique software, the customer is most familiar with 
its operation. This is especially important for payloads 
with PGSC commands which, for example, initiate an 
irreversible experiment sequence. Having an experienced 
payload representative operating the PGSC helps avoid any 
accidental mission-critical commanding which could ruin an 
experiment before it even leaves the ground. 

Operations Scheduling — Once in the orbiter flow, the 
payload is at the mercy of the orbiter integrated schedule. It 
is helpful to have KSC provide advance notification when 
work is delayed or scrubbed. Since the small payload team 
typically cannot support contiguous multi-shift operations, 
the I&T manager must remain cognizant of potential 
schedule impacts. Ideally, any rescheduling of payload 
operations should be discussed with all parties involved 
before being finally decided and implemented. 

It is sometimes unclear who is the single-point-contact for 
payload operations during orbiter integration: the payload 

ops representative from KSC Payload Ground Operations 
Contractor (PGOC) or from the Shuttle Flight Operations 
Contractor (SFOC). If on-hand, the PGOC payload ops 
representative is usually considered the single-point contact 
for scheduling payload operations. However, while at the 
OPF, the SFOC payload ops person is the contact of choice, 
since he/she is a more direct line to the orbiter world. 

Unfortunately, while quite helpful in providing support, 
payload ops personnel have any authority over prioritizing 
operations. Ultimately, it is left to the payload I&T 
manager to advocate for KSC support on behalf of the 
payload. In this respect, the I&T manager should not be 
timid. It behooves the I&T manager to diplomatically 
"lobby" for payload operations to remain on schedule as 
much as possible, through discussions with key KSC 
operations personnel. 

To help mitigate against potential support discrepancies, a 
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pretask briefing should be held with all participants the day 
prior to (not morning of) the operation. Having KSC 
complete pre-ops (such as crane and access preps) the day 
before a major operation is also helpful. 

Contamination Control— Contamination control during 
orbiter integration, particularly in the OPF, is somewhat 
less stringent than in the PPF. In the case of side-mounted 
payloads, staging in the relatively unclean OPF transfer isle 
can introduce contamination. Here, and even in the payload 
bay itself when payloads are not installed, KSC personnel 
are not required to wear cleanroom garments. 

Therefore, the I&T manager should request that all 
personnel in the vicinity of the payload wear proper 
cleanroom attire. The LSSP and OMRSD should also 

include explicit cleanliness requirements, if applicable. 
These measures not only help mitigate risk of 
contamination, but also help instill a more diligent level of 
awareness in the handling of flight hardware. 

Also at the OPF is the risk of FOD being introduced inside 
the payload bay. This is particularly a concern during 
installation of side-mounted payloads, which require 
frequent handling of fasteners and tools. Since non-captive 
fasteners can not be tethered, one suggestion is to install a 
temporary tarp or other FOD capture device directly below 
the hardware being installed. This is especially important 
in bays where the payload bay liner has been removed. It 
also helps to have spare fasteners on-hand, so integration can 
continue if a fastener is temporarily lost. 

Another problem encountered during installation of side- 
mounted payloads is the fact that orbiter technicians usually 
do not wear gloves to install fasteners. This introduces the 
risk of transferring fastener grease to the payload. Even if 
gloves are worn, grease can still be transferred to the payload 
if they are not changed-out after handling fasteners. 

At the pad. Payload Changeout Room (PCR) cleanliness is 
significantly better than at the OPF. The primary concern at 
the pad is debris from operations or other payloads situated 
above, as well as occasional incidences involving the 
Payload Changeout Room (PCR) ventilation system. This 
can be mitigated through the use of a debris shield installed 
directly above the payload in the Payload Changeout Room 
(PCR), requested via the LSSP and PRD. 

There are, however, a couple of issues associated with a 
debris shield. First, the installation of the shield can 
increase the risk of contaminants falling onto the payload, or 
the payload being accidentally contacted. Second, the 
shield itself is sometimes not a contiguous piece of material, 
and therefore doesn’t always fully protect the payload from 
falling dust and debris. Third, the proximity of an adjacent 
payload installed above may not allow enough clearance for 
a debris shield. 

In summary, there are cases when a debris shield is not 
feasible nor desirable. In these situations, the best one can 
do is to fully inspect the payload during pad closeouts, and 


clean as necessary for flight. 

Payload Handling Issues— Over the years, many incidences 
have been reported of damage to payload flight hardware, 
particularly during orbiter integration. In addition, some 
practices which have become almost standard for flight 
hardware development (e.g., use of wrist-stats and gloves) 
are not usually implemented during orbiter processing. 

Some of these handling requirements can be addressed in the 
LSSP, but should also be noted in the applicable WAD to 
ensure visibility. For operations involving payload-to- 
payload interfaces, the I&T manager must be diligent about 
ensuring that only payload personnel execute them. 

In cases where the payload contains ordnance, everyone 
working with the hardware should be reminded that ESD 
protection is mandatory when handling the hardware. It is 
also helpful to have extra conductive gloves on-hand during 
orbiter operations, since these are difficult to come by in the 
OIF’s. 

Physical Interfaces — Mechanical and electrical interfaces 
between the payload and orbiter are integrated per WAD’s 
such as TO’s and TPS’s. However, if the hardware does 
not match the documentation, some form of Problem 
Reporting And Corrective Action (PRACA) paperwork is 
usually opened, and a real-time modification with follow-up 
documentation is required. 

Performing a configuration verification on the payload 
hardware, as mentioned earlier, can help avoid some 
conflicts prior to orbiter integration. For example, one 
Hitchhiker payload had the wrong keel trunnion installed, 
which wasn’t discovered until orbiter installation. 

One payload electrical interface which causes recurring 
difficulties is the 0-AWG Standard Mixed Cargo Harness 
(SMCH) power cable. In several instances, the payload-to- 
orbiter ICD has referenced a cable length or routing which 
was physically impossible to implement. If the payload has 
any cross-bay cables (provided in advance to SFOC for 
installation), routing should be verified by the payload as 
soon as possible to insure the cables can be connected 
properly prior to IVT. Since the actual routing of payload 
cables is difficult to define prior to orbiter integration, a 
change to the ICD and/or IRD is often required. 

Payload-to-Orbiter IVT 

Scope — Strictly speaking, the orbiter IVT is limited to 
exercising only those power and signal functions required to 
verify copper path interfaces between the payload and orbiter, 
or payload-to-payload interfaces connected after orbiter 
installation. It should be noted that because side-mounted 
payloads typically involve more payload-to-payload mates 
during orbiter integration, more interfaces need to be verified 
during their IVT’s. 

Since the IVT is considered a copper-path verification, no 
functional testing is usually perfonned. Despite this, there 
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is occasionally some limited amount of functional testing 
performed in conjunction with IVT. This may be 
acceptable if there is sufficient technical justification, such as 
a late, prelaunch instrument calibration. Even if justifiable, 
scheduling and access are usually the most significant issues 
associated with functional testing. It should be noted that 
every additional payload command (sent via LPS) can 
require as many as a half-dozen additional OMI steps to 
implement, as well as additional bit patterns defined in PIP 
Annex 4, 

An alternative to performing payload functional testing 
within the context of the IVT is to conduct a stand-alone 
test independent of orbiter power. This is typically 
performed via a payload test connector and external, drag-on 
power supply. 

Regardless of the approach, all requirements for testing in 
the orbiter must be documented in the OMRSD in order for 
KSC to officially acknowledge and support them. 

Procedure Development— The I&T manager, or designee, 
typically provides KSC with inputs required for IVT OMI 
development. This is usually done several months prior to 
delivery to KSC. Any steps performed in the OMI should 
have a corresponding OMRSD requirement which is 
ultimately fulfilled through their implementation. 

Historically, some payloads have had an "IVT support 
procedure" to be run by payload support personnel in 
conjunction with KSC’s IVT OMI. However, this can be 
cumbersome, not only to maintain as procedurally 
consistent with the OMI, but also to run in parallel with the 
IVT. If the IVT is written accurately, then no other support 
procedure should be required. Possible exceptions include 
pre- or post-ops, or those payload-specific operations outside 
the scope of the IVT itself. 

Scheduling — It is most beneficial if KSC schedules the 
payload-to-orbiter IVT as soon as possible following 
payload installation and connection to the orbiter. This 
helps small payload teams minimize travel, since many of 
the same people who support installation also support IVT 
and subsequent close-outs. 

In addition, delaying the IVT a week or more beyond 
installation introduces potential risks to the overall 
schedule. One example was the IEH-1 Hitchhiker IVT 
(STS-69), which was originally scheduled about a week 
after installation into the orbiter. Unexpected circumstances 
(including roll-back due to a hurricane) delayed the IVT 
until two months later, potentially impacting the launch 
schedule. 

Near-Term Preparations — A day or so prior to the IVT, 
KSC usually conducts a pretest briefing, during which a 
timeline and dev package are distributed. This meeting 
should be attended by the I&T manager, who typically acts 
as the payload TC during the IVT. In this capacity, he/she 
is the primary payload contact during the test and is the 
communication link between the payload and KSC teams 
on the Operational Intercommunication System (OIS) “net.” 
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During the briefing, the I&T manager should also verify 
with KSC that: 

• All KSC equipment required to support IVT (e.g., 
MGSE, bridge bucket) is on-hand and functionally 
tested no later than the day before IVT; 

• Those networks required during IVT, such as OIS 
and CCTV, will be functionally tested end-to-end 
the day before IVT (if earlier, then patching could 
be inadvertently changed; if later, then systems 
may not be ready in time for call-to-stations); 

• Payload access platforms (if required) will be 
installed, also the day prior to IVT; 

• Dedicated bridge bucket support (if IVT at the 
OPF) will be available; bucket operators should be 
available on-station from pre- to post-ops, as 
necessary; 

• KSC orbiter and payload personnel supporting the 
IVT are aware of respective responsibilities, 
particularly with regards to PGSC operations (if 
applicable); 

• For ordnance operations, local clear and RF silence 
will be established at the proper point in the 
procedure. 

In addition, the payload TC should hold a separate pretest 
briefing with the payload team, usually after the KSC pretest 
briefing. This would include payload-specific details such 
as personnel assignments and stations, and any customer 
support issues. Everyone supporting the IVT in the OIF 
should have the proper training and certifications, and any 
necessary escorts should be prearranged. Finally, the 
payload team should be reminded of their OIS call-signs, 
and proper on-net etiquette. 

Performing the pre-IVT walkdown the day before (vs. the 
day of) is also highly recommended. This allows at least 
one shift to address any issues discovered during the 
walkdown. For example, in the case of Mighty Sat/S AC- A 
Hitchhiker (STS-88), the walkdown was scheduled only 
two hours prior to call-to-stations. During the walkdown, 
the orbiter/payload interface cables were found to have been 
routed in the bay too tight. The payload activation was 
delayed several hours while KSC technicians adjusted the 
cables. 

Finally, the I&T manager is responsible for ensuring that all 
payload-provided test equipment is available, such as 
PCSC’s, scopes, meters, and any payload-unique GSE. In 
the case of the PGSC, a flight-like unit is borrowed from 
JSC via the RFS form, as is done for stand-alone testing. 
The final flight software load (or as close to it as possible) 
should be used during the orbiter IVT, to help ensure that 
the payload-unique software will operate properly during the 
mission. 

Performing the IVT— As mentioned earlier, the same 
individuals who participated in the IVT sim should 
participate in the actual orbiter IVT. In the case of 
Hitchhikers, the payload TC is usually stationed at the 
PPF. This allows easy communication with the customers 
and viewing of telemetry and video monitors, as applicable. 
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Any extraneous observers should also be located at the 
PPF. 

The Hitchhiker mission manager usually supports from the 
firing room, where the KSC payload test conductor and 
engineers are stationed. At that location, he or she is able 
to provide any payload customer signatures required on any 
devs or PRACA. 

For orbiter aft flight deck operations, crew support is the 
first choice, if available. If a PGSC is required for IVT, the 
operator should be the payload software engineer when crew 
is unavailable. In any case, it is up to the payload TC to 
decide who is best qualified to operate the PGSC, with 
concurrence from project management. Of course, the 
operators should have all the training and certifications 
required for crew module access. 

Payload personnel may also be required to support from the 
payload bay. They should arrive at the OIF early enough to 
allow time to check-in all test equipment and tools with the 
access monitor. As usual, any test equipment required to 
support IVT in the payload bay must be tetherable and 
secured. 

All personnel supporting the IVT should be on-station at 
least one-half hour prior to start of their pre-ops or call-to- 
stations, as applicable. The payload team should utilize the 
separate, preassigned OIS channel for any off-line 
discussions during the IVT. On-line communications are 
restricted to responses as called out in the procedure itself, 
with the payload TC responding for the rest of the team 
unless otherwise specified. Telephones should be used for 
extended conversations or those unrelated to the IVT. 

Upon completion of all testing, any payload GSE can be 
packed for shipment to the POCC if required to support the 
mission. 

Closeouts and Launch Operations 

Closeouts — Some payload operations must be performed as 
late as possible prior to launch. This typically means no 
later than a day or so prior to final payload bay door closure 
either at the OPF or pad. Late payload operations generally 
do not involve orbiter power; therefore, any testing requires 
stand-alone power supplies. Testing may include, for 
example, a last-minute instrument calibration or battery top- 
charge. 

Payload closeouts are those operations required to finally 
configure the payload for flight, including: 

• Removing "remove-before-flight" (or "red-tag") 
items, such as dust covers and purge lines; 

• Installing arm plugs for ordnance or other 
functions, such as enabling satellite batteries; 

• Verifying armed circuits, for example, via 
continuity measurements at a test connector; 

• Performing a walkdown of the payload to verify 
configuration, cleanliness, and that all nonflight 
items have been removed. 


Payload closeout requirements, whether at the OPF or pad, 
must also be predefined in the OMRSD. Since these are 
generally performed by payload personnel, they are usually 
specified in a separate payload procedure. 

Launch— Unless the payload is powered during launch, or a 
"T-0 interface” is utilized, payload personnel are usually not 
required to support launch at KSC. Instead, payload 
representatives should be stationed at the POCC for payload 
activation. 

The I&T manager may or may not be required to support 
throughout the mission. I&T may just be on-call in case a 
problem develops which requires his or her expertise. 

8. Postflight Operations 

At ksc 

Postlanding and Orbiter Deintegration — As with launch, 
payload personnel are generally not required to support 
landing. Any postlanding operations are performed in the 
OPF following payload bay door opening. The only 
postlanding, stand-alone operations for small payloads are 
usually dust cover reinstallations and safing of ordnance 
circuits, if necessary. Again, any requirements for 
operations in the orbiter must be documented in the 
OMRSD. 

Electrical disconnections are performed in the OPF, usually 
in the reverse order of connection, with the same respective 
KSC and payload responsibilities noted earlier. Payload 
transfer back to the PPF is also performed in essentially the 
reverse order of prelaunch integration. Any payload- 
provided cables removed from the payload bay should be 
returned to the payload organization. 

PPF Operations — Once the payload arrives back at the PPF, 
it is generally prepared for shipment back to the home 
facility. For Hitchhikers, no activation of the payload is 
performed at the PPF postflight. 

In some cases, customers request that specific postflight 
operations, such as data retrieval or even instrument 
deintegration, be performed at the PPF. However, it is 
recommended that customer hardware be deintegrated after 
return to the home facility, unless there is sufficient technical 
justification. Performing work at KSC beyond the 
minimum required to ship the payload back home requires 
more procedures to be run at KSC. This tends to increase 
the time in the field, as well as the probability of 
encountering unforeseen problems. 

For example, following the flight of IEH-1 (STS-69), the 
CONCAP-IV/03 customer requested that the canister be 
removed from the payload and deintegrated. Although this 
had not been the original plan, the consensus was that it 
would help expedite experiment sample removal, as well as 
eliminate the need for the customer to travel to Goddard. 
Unknown to all was that one of the sample vials, which 
contained a hazardous substance, had broken within the can. 
When the canister was opened the noxious gas escaped, 
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resulting in a hazardous situation inside a KSC facility. 
Fortunately, no one was injured, but a valuable lesson had 
been learned at a risk to human health. 

Back at the Ranch 

Deintegration — Upon return to its home facility, the 
payload and GSE are off-loaded and inspected for damage. 
Any postflight troubleshooting deemed necessary should be 
performed before any hardware is deintegrated from the 
payload. 

As with integration, deintegration is performed in the most 
logical sequence. Removal of customer hardware depends 
on accessibility of the hardware, as well as availability of the 
customers themselves. For Hitchhikers, carrier hardware 
remains installed if necessary to support a subsequent 
mission. However, generally all mission-unique hardware 
is removed from the payload and returned to storage fa* 
future use. 

Documentation — Following post-mission activities, at 
his/her earliest convenience, the I&T manager should 
compile and distribute a summary of any "lessons learned." 
This includes significant I&T-related issues experienced 
and any suggestions for improvement. Specific team 
members should also be commended for their efforts. 

In addition, the I&T manager should provide some feedback 
to KSC regarding operations in the field. This may include 
a KSC payload customer survey, Opportunity For 
Improvement (OFI) form, or simply a summary to key 
individuals. 

Payload customers should be asked to submit some form of 
customer survey to help the payload team gain some insight 
for improving customer support and payload processing. 
The format for the customer survey used for Hitchhikers can 
be found at the SSPPO website. 

Finally, all payload documentation and logbooks (including 
as-run procedures) should be archived, to make them 
available for future reference. Of course, all problem records 
should be dispositioned and closed prior to archiving. 
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